home *** CD-ROM | disk | FTP | other *** search
- Internet Draft
- Network Services Monitoring MIB
-
- Ned Freed
- Steve Kille
-
- MADMAN Working Group
- August 18, 1993
- Expires: February 18, 1994
-
- 1. Status of this Memo
-
- This document is an Internet Draft. Internet Drafts are working
- documents of the Internet Engineering Task Force (IETF), its Areas,
- and its Working Groups. Note that other groups may also distribute
- working documents as Internet Drafts.
-
- Internet Drafts are draft documents valid for a maximum of six
- months. Internet Drafts may be updated, replaced, or obsoleted by
- other documents at any time. It is not appropriate to use Internet
- Drafts as reference material or to cite them other than as a "working
- draft" or "work in progress."
-
- To learn the current status of any Internet-Draft, please check the
- 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
- Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com,
- or munnari.oz.au.
-
- 2. Abstract
-
- This document defines the generic part of a MIB suitable for
- monitoring applications which provide some variety of network
- service. This MIB is intended to be extended to accomodate
- monitoring specific to a given type of service, for example, a
- Message Transfer Agent (MTA) service or a Directory Service Agent
- (DSA) service.
-
- 3. The SNMPv2 Network Management Framework
-
- The SNMPv2 Network Management Framework consists of four major
- components. They are:
-
- o RFC 1442 which defines the SMI, the mechanisms used for describing
- and naming objects for the purpose of management.
- o RFC 1213 defines MIB-II, the core set of managed objects for the
- Internet suite of protocols.
- o RFC 1445 which defines the administrative and other architectural
- aspects of the framework.
- o RFC 1448 which defines the protocol used for network access to
- managed objects.
-
- The Framework permits new objects to be defined for the purpose of
- experimentation and evaluation.
-
- 3.1 Object Definitions
-
- Managed objects are accessed via a virtual information store, termed
- the Management Information Base or MIB. Objects in the MIB are
- defined using the subset of Abstract Syntax Notation One (ASN.1)
- defined in the SMI. In particular, each object object type is named
- by an OBJECT IDENTIFIER, an administratively assigned name. The
- object type together with an object instance serves to uniquely
- identify a specific instantiation of the object. For human
- convenience, we often use a textual string, termed the descriptor,
- to refer to the object type.
-
- 4. Rationale for having a Network Services Monitoring MIB
-
- Much effort has been expended in developing tools to manage lower
- layer network facilities. However, relatively little work has been
- done on managing application layer entities. It is neither
- efficient nor reasonable to manage all aspects of application layer
- entities using only lower layer information. Moreover, the
- difficulty of managing application entities in this way increases
- dramatically as application entities become more complex.
-
- This leads to a substantial need to monitor applications which
- provide network services, particularly distributed components such
- as MTAs and DSAs, by monitoring specific aspects of the application
- itself. Reasons to monitor such components include but are not
- limited to measuring load, detecting broken connectivity, isolating
- system failures, and locating congestion.
-
- In order to manage network service applications effectively two
- requirements must be met:
-
- (1) It must be possible to monitor a large number of components
- (typical for a large organization).
-
- (2) Application monitoring must be integrated into general
- network management.
-
- SNMP is the clear choice for this sort of monitoring. At present
- only simple read-only access is defined; this is sufficient to
- determine up/down status and provide an indication of a broad
- class of operational problems.
-
- 4.1 Restriction of Scope
-
- The framework provided here is very minimal; there is a lot more that
- could be done. For example:
-
- (1) General network service application configuration monitoring and
- control.
-
- (2) Detailed examination and modification of individual entries in
- service-specific request queues.
-
- (3) Probing to determine the status of a specific request (e.g. the
- location of a mail message with a specific message-id).
-
- (4) Requesting that certain actions be performed (e.g. forcing an
- immediate connection and transfer of pending messages to some
- specific system).
-
- All these capabilities are both impressive and useful. However,
- these capabilities would require provisions for strict security
- checking. These capabilities would also mandate a much more complex
- design, with many characteristics likely to be fairly
- implementation-specific. As a result such facilities are likely to
- be both contentious and difficult to implement.
-
- This document religiously keeps things simple and focuses on the
- basic monitoring aspect of managing applications providing network
- services. The goal here is to provide a framework which is simple,
- useful, and widely implementable.
-
- 4.2 Relationship to Directory Services
-
- Use of and management of directory services already is tied up with
- network service application management. There are clearly many things
- which could be dealt with by directory services and protocols. We
- take the line here that static configuration information is both
- provided by and dealt with by directory services and protocols.
- The emphasis here is on transient application status.
-
- By placing static information in the directory, the richness and
- linkage of the directory information framework does not need to be
- repeated in the MIB. Static information is information which has a
- mean time to change of the order of days or longer.
-
- When network service applications that employ directory services
- are monitored, it is recommend that a linkage be established, so
- that:
-
- (1) The managed object contains its own directory name. This
- allows all directory information to be obtained by reference.
- This will let a SNMP monitor capable of performing directory
- queries present this information to the manager in an
- appropriate format. It is intended that this will be the
- normal case.
-
- (2) The directory will reference the location of the SNMP agent,
- so that an SNMP capable directory query agent could probe
- dynamic characteristics of the object.
-
- (3) This approach could be extended further, so that the SNMP
- attributes are modelled as directory attributes. This would
- dramatically simplify the design of directory service agents
- that use SNMP to obtain the information they need.
-
- 5. Application Objects
-
- This MIB starts with a set of general purpose attributes which would
- be appropriate for a range of applications that provide network
- services. Both OSI and non-OSI services can be accomodated.
- Additional tables defined in extensions to this MIB provide attributes
- specific to specific network services.
-
- A table is defined which will have one row for each network service
- application running on the system. The only static information held
- on the application is its name. All other static information should
- be obtained from various directory services. The applName is an
- external key, which allows an SNMP MIB entry to be cleanly related
- to the X.500 Directory. In SNMP terms, the applications are grouped
- in a table called applTable, which is indexed by an integer key
- applIndex.
-
- The type of the application will be determined by one or both of:
-
- (1) Additional MIB variables specific to the applications.
-
- (2) An association to the application of a specific protocol.
-
- 6. The Application MIB
-
- APPLICATION-MIB DEFINITIONS ::= BEGIN
-
- IMPORTS
- OBJECT-TYPE, experimental, Counter32, Gauge32
- FROM SNMPv2-SMI
- DisplayString, TimeStamp
- FROM SNMPv2-TC;
-
- application MODULE-IDENTITY
- LAST-UPDATED ""
- ORGANIZATION "IETF Mail and Directory Management Working Group"
- CONTACT-INFO
- " Ned Freed
-
- Postal: Innosoft International, Inc.
- 250 West First Street, Suite 240
- Claremont, CA 91711
- US
-
- Tel: +1 909 624 7907
- Fax: +1 909 621 5319
-
- E-Mail: ned@innosoft.com"
- DESCRIPTION
- "The MIB module describing network service applications"
- ::= {experimental 46}
-
- applObjects OBJECT IDENTIFIER ::= {application 1}
-
-
- -- The basic applTable contains a list of the application
- -- entities.
-
- applTable OBJECT-TYPE
- SYNTAX SEQUENCE OF ApplEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The table holding objects which apply to all different
- kinds of applications providing network services."
- ::= {applObjects 1}
-
- applEntry OBJECT-TYPE
- SYNTAX ApplEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry associated with a network service application."
- INDEX {applIndex}
- ::= {applTable 1}
-
- ApplEntry ::= SEQUENCE {
- applIndex
- INTEGER,
- applName
- DisplayString,
- applVersion
- DisplayString,
- applUptime
- TimeStamp,
- applOperStatus
- INTEGER,
- applLastChange
- TimeStamp,
- applInboundAssociations
- Gauge32,
- applOutboundAssociations
- Gauge32,
- applAccumulatedInboundAssociations
- Counter32,
- applAccumulatedOutboundAssociations
- Counter32,
- applLastInboundActivity
- TimeStamp,
- applLastOutboundActivity
- TimeStamp,
- applRejectedInboundAssociations
- Counter32,
- applFailedOutboundAssociations
- Counter32
- }
-
- applIndex OBJECT-TYPE
- SYNTAX INTEGER (1..2147483647)
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An index to uniquely identify the network service
- application."
- ::= {applEntry 1}
-
- applName OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The name the network service application chooses to be
- known by."
- ::= {applEntry 2}
-
- applVersion OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The version of network service application software."
- ::= {applEntry 3}
-
- applUptime OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime at the time the network service
- application was last initialized. If the application was
- last initialized prior to the last initialization of the
- network management subsystem, then this object contains
- a zero value."
- ::= {applEntry 4}
-
- applOperStatus OBJECT-TYPE
- SYNTAX INTEGER {
- up(1),
- down(2),
- halted(3),
- congested(4),
- restarting(5)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Indicates the operational status of the network service
- application. 'down' indicates that the network service is
- not available. 'running' indicates that the network service
- is operational and available. 'halted' indicates that the
- service is operational but not available. 'congested'
- indicates that the service is operational but no additional
- inbound associations can be accomodated. 'restarting'
- indicates that the service is currently unavailable but is
- in the process of restarting and will be available soon."
- ::= {applEntry 5}
-
- applLastChange OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime at the time the network service
- application entered its current operational state. If
- the current state was entered prior to the last
- initialization of the local network management subsystem,
- then this object contains a zero value."
- ::= {applEntry 6}
-
- applInboundAssociations OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of current associations to the network service
- application, where it is the responder. For dynamic single
- threaded processes, this will be the number of application
- instances."
- ::= {applEntry 7}
-
- applOutboundAssociations OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of current associations to the network service
- application, where it is the initiator. For dynamic single
- threaded processes, this will be the number of application
- instances."
- ::= {applEntry 8}
-
- applAccumulatedInboundAssociations OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of associations to the application entity
- since application initialization, where it was the responder.
- For dynamic single threaded processes, this will be the
- number of application instances."
- ::= {applEntry 9}
-
- applAccumulatedOutboundAssociations OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of associations to the application entity
- since application initialization, where it was the initiator.
- For dynamic single threaded processes, this will be the
- number of application instances."
- ::= {applEntry 10}
-
- applLastInboundActivity OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime at the time this application last
- had an inbound association. If the last association
- occurred prior to the last initialization of the network
- subsystem, then this object contains a zero value."
- ::= {applEntry 11}
-
- applLastOutboundActivity OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime at the time this application last
- had an outbound association. If the last association
- occurred prior to the last initialization of the network
- subsystem, then this object contains a zero value."
- ::= {applEntry 12}
-
- applRejectedInboundAssociations OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of inbound associations the application
- entity has rejected, since application initialization."
- ::= {applEntry 13}
-
- applFailedOutboundAssociations OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number associations where the application entity
- is initiator and association establishment has failed,
- since application initialization."
- ::= {applEntry 14}
-
-
- -- assocTable augments the information in applTable with data
- -- about associations. This is treated as a separate group to
- -- the basic application table. Where simplified appplication
- -- monitoring is needed, the assocTable group may be omitted.
- -- This table is indexed by applIndex and assocIndex, with the
- -- application index coming first.
-
- assocTable OBJECT-TYPE
- SYNTAX SEQUENCE OF AssocEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The table holding a set of all active application
- associations."
- ::= {applObjects 2}
-
- assocEntry OBJECT-TYPE
- SYNTAX AssocEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry associated with an association for a network
- service application."
- INDEX {applIndex, assocIndex}
- ::= {assocTable 1}
-
- AssocEntry ::= SEQUENCE {
- assocIndex
- INTEGER,
- assocRemoteApplication
- DisplayString,
- assocApplicationProtocol
- OBJECT IDENTIFIER,
- assocApplicationType
- INTEGER,
- assocDuration
- TimeStamp
- }
-
- assocIndex OBJECT-TYPE
- SYNTAX INTEGER (1..2147483647)
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An index to uniquely identify each association for a network
- service application."
- ::= {assocEntry 1}
-
- assocRemoteApplication OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The name of the system running remote network service
- application. For an IP-based application this should be
- either a domain name or IP address. For an OSI application
- it should be the string encoded distinguished name of the
- managed object. For X.400(84) MTAs which do not have a
- Distinguished Name, the RFC-1327 syntax 'mta in globalid'
- should be used."
- ::= {assocEntry 2}
-
- assocApplicationProtocol OBJECT-TYPE
- SYNTAX OBJECT IDENTIFIER
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "An identification of the protocol being used for the
- application. For an OSI Application, this will be the
- Application Context. For Internet applications, the IANA
- maintains a registry of the OIDs which correspond
- to well-known applications. If the application protocol is
- not listed in the registry, the value {applProtoID port} is
- used where 'port' corresponds to primary port being used by
- the application."
- ::= {assocEntry 3}
-
- assocApplicationType OBJECT-TYPE
- SYNTAX INTEGER {
- ua-initiator(1),
- ua-responder(2),
- peer-initiator(3),
- peer-responder(4) }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Shows whether the remote application is a User Agent, or a
- peer server, and whether the remote end is initiator or
- responder."
- ::= {assocEntry 4}
-
- assocDuration OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime at the time this association was
- started. If this association started prior to the last
- initialization of the network subsystem, then this
- object contains a zero value."
- ::= {assocEntry 5}
-
-
- -- Conformance information
-
- applConformance OBJECT IDENTIFIER ::= {application 2}
-
- applGroups OBJECT IDENTIFIER ::= {applConformance 1}
- applCompliances OBJECT IDENTIFIER ::= {applConformance 2}
-
- -- Compliance statements
-
- applCompliance MODULE-COMPLIANCE
- STATUS current
- DESCRIPTION
- "The compliance statement for SNMPv2 entities
- which implement the Network Services Monitoring MIB
- for basic monitoring of network service applications."
- MODULE -- this module
- MANDATORY-GROUPS {applGroup}
- ::= {applCompliances 1}
-
- assocCompliance MODULE-COMPLIANCE
- STATUS current
- DESCRIPTION
- "The compliance statement for SNMPv2 entities
- which implement the Network Services Monitoring MIB
- for basic monitoring of network service applications
- and their associations."
- MODULE -- this module
- MANDATORY-GROUPS {applGroup, assocGroup}
- ::= {applCompliances 2}
-
-
- -- Units of conformance
-
- applGroup OBJECT-GROUP
- OBJECTS {
- applIndex, applName, applVersion, applUptime,
- applOperStatus, applLastChange, applInboundAssociations,
- applOutboundAssociations, applAccumulatedInboundAssociations,
- applAccumulatedOutboundAssociations, applLastInboundActivity,
- applLastOutboundActivity, applRejectedInboundAssociations,
- applFailedOutboundAssociations }
- STATUS current
- DESCRIPTION
- "A collection of objects providing basic monitoring of
- network service applications."
- ::= {applGroups 1}
-
- assocGroup OBJECT-GROUP
- OBJECTS {
- assocIndex, assocRemoteApplication,
- assocApplicationProtocol, assocApplicationType,
- assocDuration }
- STATUS current
- DESCRIPTION
- "A collection of objects providing basic monitoring of
- network service applications' associations."
- ::= {applGroups 2}
-
-
- -- Values of the form { applProtoID port } are used for
- -- protocols that don't have assigned OIDs. 'port'
- -- corresponds to primary port being used by the
- -- application.
-
- applProtoID OBJECT IDENTIFIER ::= {application 3}
-
- END
-
- Expires: February 18, 1994
-
-